Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/mail/metamail/CSCW-ATOMICMAIL.txt

Text File | 1992-12-22 | 35.7 KB | 645 lines

Computational Mail as Network Infrastructure/Borenstein                1


Computational Mail as Network Infrastructure
for Computer-Supported Cooperative Work


Nathaniel S. Borenstein
Bellcore

Abstract

Computational email -- the embedding of programs within electronic mail
messages -- is proposed as a technology that may help to solve some of the
key problems in deploying successful applications for computer-supported
cooperative work.  In particular, computational email promises to alleviate
the problem of remote installation at separately-administered sites, the
problem of getting users to "buy in" to new applications, and the problem of
extremely heterogeneous user interaction environments.  In order for
computational email to be practical, however, key problems of security and
portability must be addressed, problems for which this research offers new
solutions.    This paper outlines the promise of this new technology, the
solutions to the key technical problems, and the areas where further work
and application development are needed.

The Goal:  Distributed Computer-Supported Cooperative Work

In recent years, increasing attention has been focused on the problem of
computer-supported cooperative work (CSCW).  This work, broadly defined, is
the attempt to provide computer-based solutions to the problems that arise
when two or more people attempt to cooperate to perform a task or solve a
problem.

The simplest CSCW systems, from an architectural perspective, are those in
which the cooperating individuals share a computerized application on a
single machine, perhaps even using a single process.  In such systems, many
problems of coordination and communication can be avoided.  However, such
systems are increasingly implausible for solving the problems of real-world
users, who may be widely separated geographically and may have significant
amounts of computing power on their individual desks.  Truly distributed
applications seem natural in the face of a high ratio of computing power to
available communications bandwidth.  For many cooperative applications,
distributed solutions seem inevitable, and indeed a growing number of CSCW
prototypes are implemented in a distributed manner.

Unfortunately, the practical success of such systems to date has been
extremely limited.  This paper begins with a discussion of three key problems
that have inhibited the widespread use of distributed applications for CSCW.
Following this, the paper offers a description of a new technology,
"computational electronic mail (email)", that offers a potential solution to
these problems.  Problems that have, in the past, rendered computational
email impractical are discussed, along with proposed solutions to these
problems.  Following this is a discussion of the author's particular realization
of these solutions, a language designed specifically for the unusual
requirements of computational email.  The design of this language and its
prototype implementation are presented as a "proof-of-concept" for the
practicality of computational email.  The preliminary results of that
implementation, and its implication for future systems, are discussed briefly
at the end of the paper.

The Practical Difficulty of Widely-Distributed User-Oriented
Computation

When building a user-oriented distributed application, the programmer faces
a special set of constraints above and beyond the usual substantial hurdles
entailed in every new user interface.  In particular, he or she must solve at
least three problems that are not generally faced by single-user or single-
machine applications:

  I.  The Problem of Remote Installation

In order for an application to be used by multiple users at multiple sites, it
must, perforce, be installed at all such sites.  This is not a problem for
applications in which all of the potential users are eager and knowledgeable
participants, in which case they can be counted on either to install the
software themselves or request such installation by the local authorities.
However, this is by no means the normal situation for distributed
applications.  In many distributed systems, as noted by Grudin [Grudin, 1990],
there is a substantial imbalance between the motivations of the various
particpants.  A common scenario, for example, involves one user asking a
question of a group of users.  In such a situation, it is much more reasonable
to expect the questioner to ensure the local installation of some CSCW
software than to expect it of the people being asked.

In short, the participants in a cooperative application often have widely
differing degrees of motivation, and are therefore likely to exert similarly
varying degrees of persistence and effort in order to ensure that the software
for that application is locally installed.  Almost inevitably, this leads to a
situation in which the highly-motivated individuals find themselves
wheedling, cajoling, or even begging the less motivated individuals to install
the software on their systems.  Without extreme persistence, CSCW
applications can fail without ever really being tried, simply because a
sufficient installed user base was never created.

  II.  The Problem of User Buy-In

Related to the problem of getting software installed at widely distributed
sites is the problem of getting people to actually use the software once it is
installed.  Because of the differing motivations of the participants, it is likely
that some users are far more likely than others to actually run the software.
As Grudin has noted, the users who are most crucial to the success of a CSCW
application often have the least personal stake in using it.  For example, in
any system that seeks to help novices get information from experts, the
experts who know the answers have relatively little motivation to provide it.
Some systems, such as the Answer Garden of Malone and Ackerman
[Ackerman and Malone, 1990]  rely on the good will (and memory) of the
experts to periodically run a program to see if anyone needs help.  Since the
necessary combination of good will, reliability, and memory are relatively
rare, this requirement can be crippling to the practical success of a system.

  III.  The Problem of Heterogeneous User Environments

For better or worse, there are a wide variety of user interaction environments
in use today, and this seems unlikely to change in the foreseeable future.
Potential participants in a cooperative application may be running on dumb
terminals, Macintoshes, personal computers running MS-DOS with or without
MS-Windows, OS/2 with Presentation Manager, UNIX with X11, SunTools,
NeWS, or various other environments.  It is unlikely, to say the least, that the
purveyors of a cooperative application will be able to dictate, to all potential
users of the system, a single interaction environment.  (Malone and
Ackerman's Answer Garden was an exception in this regard:  they were able
to assume that all users were running X11, for the simple reason that their
application domain was questions and answers about the X11 system itself.)

In order for a distributed application to see widespread use and acceptance, it
will have to run on a very wide variety of platforms, probably including all
the ones just mentioned.  But, as programmers well know, getting any piece of
software to work on such a variety of platforms is a major task in itself,
above and beyond the main thrust of the cooperative application.

Needed:  A Platform On Which to Build

If all of these problems afflict a wide variety of cooperative applications, it
seems natural to seek a mechanism to solve them for the entire class of
applications, rather than for each application individually.  What is really
needed is a platform on which distributed applications can be built without
concern for the problems of distribution, user buy-in, and heterogeneous
interaction environment.

If a computational engine can be defined in such a way as to support the
requirements of many cooperative applications, yet without commitment to a
particular user interaction technology, and if that single engine can somehow
overcome the first problem, the problem of remote installation, then neither
the problem of remote installation nor the problem of heterogeneous user
environments will afflict applications that are built on top of such an engine.
This leaves the problem of user buy-in:  assuming such an engine were
defined and widely implemented and installed, how could users be persuaded
to use it regularly?  One solution is to "piggyback" the engine on top of a
technology that is already at the fingertips of most computer users today,
electronic mail.

The Case for Computational Email

The basic idea of computational email is very simple:  Instead of sending
plain text, or even multimedia information, in a mail message, what is sent
instead is a computer program in a well-defined language.  At the recipient's
end, the mail-reading software recognizes (via a well-defined mechanism)
that the mail message is intended to be executed rather than read, and
(accordingly) executes it.  Thus, when the recipient reads a mail message, the
message might first show him some introductory text, and then engage him in
a question/answer dialogue.  For example, it might ask him to select which of
ten proposed dates and times he can make it to a meeting.  The program
might then mail the answers back to a network server that was collecting
such answers from several such people, in order to find a meeting time
suitable to all of them.

The greatest appeal in the idea of embedding applications within email is the
simple way it solves the problem of user buy-in.  Because nearly everyone
who uses a networked computer nowadays is likely to be a regular reader of
email, an application that is delivered to a user in the form of email requires
no special effort or feat of memory, on the part of the recipient, in order to
run it.  Most important, remote users of a distributed application can, by
embedding computation in email, solicit information or participation from a
user who does not yet know that his participation is required.

While the idea of embedding computation in email suffers no less than any
other application from the problems of distributing the initial software and
devising an interaction mechanism that works regardless of interaction
environment, it can be designed in such a way that the solution of the
problem for computational email makes the problem simply nonexistent for
applications built on a platform of computational email.  In other words,
solving the remote installation once, for a computational email infrastructure,
will solve it for a whole class of follow-on applications.

Prior Art

The idea of computational or "active" mail is sufficiently simple as to have
been mentioned, in the research literature, at least fifteen years ago, in a
paper by Anderson and Gillogly [Anderson and Gillogly, 1976], who discussed
the concept without implementing it.   Several researchers have implemented
computational email, or "active messaging," including Vittal [Vittal, 1981],
Hogg [Hogg, 1985], Borenstein and Hansen [Borenstein, 1991a, and Hansen,
1990], and Shepherd [Shepherd, 1990].  Each of these systems demonstrated
facilities for embedding computation and email, and several offered
convincing evidence for the general utility of such a facility.

Nonetheless, all of the prior work has suffered from at least two of four
crucial flaws, which have prevented a generalized facility for computational
email from becoming widely available:

1.  Lack of generality.  Some systems, notably the Andrew system
without Ness [Borenstein, 1991a], offered only highly specialized
facilities for active messages, such as special-purpose "voting" messages.
Though useful, such facilities do not provide a platform on which larger
applications can be built.

2.  Lack of conformity to the standard email transport model.  Some
systems, notably Imail [Hogg, 1985], did not use asynchronous store-
and-forward delivery, and thus might arguably not be called electronic
mail.  In particular, Imail provided a very powerful active messaging
language, but could only be used to exchange messages between
authenticated users of a single machine.  Since most email crosses
insecure network connections, such mechanisms do not generalize well
to the real world.

3.  Lack of security.  Some systems, such as R2D2 [Vittal, 1990] and
Andrew with Ness [Hansen, 1990], provided general-purpose
mechanisms that were exceedingly dangerous.  In such systems, a user
is typically asked a question such as "There is a program here.  Do you
want to try running it?"  If the user answers in the affirmative, he may
have risked the destruction of all his files.  This is probably
unacceptable to most users in the real world.

4.  Lack of portability.  Computational mail that provides a rich user
interface mechanism, such as Andrew with Ness [Hansen, 1990], or
Strudel [Shepherd, 1990], has typically been extremely non-portable
with regard to user interaction environments.  With Andrew messages,
for example, the interaction mechanisms only worked properly if the
recipient read his mail using the Andrew Messages program, under the
X11 or WM window systems.  In a highly heterogeneous world, such
restrictions are not acceptable to many communities.

Thus, although the existing literature amply documents the continuing
fascination that computational email holds for email researchers, it fails to
provide a practical model for making computational email a part of the
general shared infrastructure of a large, diverse, and not entirely trusting
network community.  This is the starting point for the research reported here.

Portability Across User Environments

Stated in the most general and ambitious manner, the goal of making user
interfaces entirely portable between a wide range of user interface
environments is probably impossible.  However, a lesser goal will suffice for
computational email.

A significant number of applications can be built using user interface
primitives that require only textual input and output, and that are specified
in a manner that assume nothing about the capabilities of the user interaction
environment.  Examples of such primitives might include:

1.  Get text (a string) from the user.

2.  Get a number from the user.

3.  Ask the user a multiple choice question.

4.  Fill in the blanks in a form.

5.  Display a chunk of text to the user.

As long as the language primitives refer only to the information that must be
given to or obtained from the user, and make no reference to the technologies
by which that information is to be given or obtained, and as long as the
information can be expressed as simple text, such primitives can be
implemented in virtually any interaction environment.  For example, a
multiple choice question might produce a dialog box for a user running in a
graphical environment, while it might produce a numbered list on a teletype,
with a request to "choose a number from 1 to 7."

What matters, in such primitives, is that the mechanism by which the
information is conveyed is left unspecified by the definition of the primitive.
Given that fact, a user can expect to compose and test a program in one
environment, secure in the knowledge that it will behave well even in a very
different environment, where the interpreter understands the same language,
even though it might interact with the user rather differently.

Security of Computational Email

The security of a computational email message is an area where virtually no
compromise is acceptable.  This might not have been true a few years ago, but
well-publicized episodes such as the Internet Worm [Spafford, 1989] have
made most computer users highly conscious of, and concerned about, the
security of their computer systems.

However, despite such concerns, it must be explicitly recognized that certain
risks are routinely accepted by the general computing public.  Conventional
electronic mail, for example, is not without risks.  The most common risk in
current mail systems is resource deprivation.  For example, by repeatedly
sending large mail messages, any network user can often fill the disk of
another, depriving him (at least temporarily) of the use of that disk.  This can
often be done completely anonymously, and can be a minor nuisance or a
major problem, depending on what else shares the disk.  Similarly, a program
that uses mail protocols on a network can, by playing "cat and mouse" with
someone else's mail transport agent, effectively tie up much of the bandwidth
available on a network, or even a substantial portion of the computational
power of the remote processor.

Beyond resource deprivation, an even more insidious risk in mail systems is
that they are vulnerable to intruders using essentially non-technical means.
Recently, many users on the Internet were told, via official looking mail, that
they had to change their passwords to "SYSTEST01" immediately; apparently
more than a few complied.  The infamous "Christmas Tree Virus" that afflicted
the IBM networks a few years back was entirely based on social engineering:
Users received mail that appeared to come from someone they knew, saying
"here's a neat program that will make an animated Christmas Tree on your
screen."  When executed, the program did exactly that, thus avoiding
suspicion, but it also sent copies of itself to all of the users' regular
correspondents.

Finally, existing mail systems, like all network software, are vulnerable to
security problems through bugs.  The Internet worm, for example, exploited a
bug in a mail transport program as one of several mechanisms for
transporting itself.

The point of the foregoing discussion is not to frighten the reader out of ever
using email again, but rather to point out that a "risk free" solution is
chimerical.  A more realistic security goal for computational email might be
characterized as follows:  Computational email should entail no security
problems that are worse, either in kind or in degree, than the problems that
afflict ordinary (textual) email.  Given such a goal, we may begin by
characterizing the potential risks into three broad categories:

1.  Destruction of Resources (e.g. files)

2.  Theft of Resources (e.g. private files)

3.  Deprivation of Resources (e.g. filling up a disk or tying up a CPU)

To understand how these problems can be addressed, it is instructive to
consider an analogy.  Imagine, for a moment, that somewhere in the
basement of the Pentagon there are two computers.  They are identical
hardware, and they run identical software; they are as alike as two peas in a
pod.  On each of them, there is an executable procedure called
"DestroyBaghdad".  On one of the machines, executing this procedure does
nothing.  On the other, the effects of executing the procedure are disastrous,
at least for the citizens of Iraq.  The only difference between the two
machines is a single wire coming out of the back of the second machine.1

The point, of course, is that nothing inherent to a computational language is
dangerous; danger is posed only insofar as the effects of executing statements
in a language include "side-effects" in the external world.  If all the "wires"
connecting a computational language to the outside world are cut, then
executing programs in that language is harmless.  (An exception to this claim
is that such a program can still tie up the CPU, virtual memory, or swap space
on a machine by going into an infinite loop; this can be handled via resource
limitations.)

More concretely, if one starts with a conventional programming language,
such as LISP [Steele, 1990], and removes all input and output from the
language (including not only input and output to and from the user, but also
to and from files, other processes, and arbitrary memory locations which
might be connected with physical devices), one is left with a language without
"wires" to the outside world.  No matter what can be expressed in such a
language, it can do no harm to the outside world.

Unfortunately, though it can do no harm, it can do little good, either.  So the
task of devising a secure language for computational email reduces, in
practice, to the construction of a secure input/output mechanism for a
conventional language.  Devising such a mechanism is really just a matter of
judicious trade-offs.  For example, one can specify that the language has no
general-purpose access to the file system, but has a limited form of access to
a subset of the file system.  In the system to be described below, programs
have access only to a restricted subdirectory of the user's files, and the
interpreter is expected to ensure that no "tricks" (such as, in UNIX, the use of
".." or symbolic links) can be used to access files outside that area.  Within
that restricted area, programs are additionally restricted in their ability to
overwrite existing files, and in the number and size of the files they can
create.  In such a way, the potential harm to the file system that is caused by
computational email is not greater than the disk-filling potential of textual
email.  Similar restrictions are applied to other input/output processes,
including sending mail.  Some security constraints also apply to user
interaction:  for example, in order to prevent subversion through the clever
exploitation of "intelligent" terminals, input and output is restricted to
printable characters.

Heterogeneous Mail Reading Software

A major impediment to any enhancements to electronic mail systems is the
tyranny of the lowest common denominator.  Multimedia mail systems such
as Andrew [Borenstein, 1991a] and Diamond [Forsdick, 1984] have long
suffered from the fact that, in the absence of widely accepted standards for
multimedia mail formats, most email traffic will necessarily be plain text,
even for users of multimedia systems, because most of their correspondents
will not be users of compatible systems.

The same problem affects any attempt to promote the use of computational
email.  In order for such a system to be widely used, it must not require the
use of a special mail-reading tool.  Instead, a mechanism is needed whereby a
wide variety of mail-reading tools can easily be given the capability to handle
computational email.

Such a mechanism has been prototyped by the author, and is described
elsewhere [Borenstein, 1991b].  Its essence, however, is simple.  Each mail-
reading user interface is modified in a small but crucial way:  it is modified so
that, whenever a user requests to see the body of a message, the software
first checks to see whether or not the message is plain text.  (In Internet mail,
this is done by checking the Content-type header field.)  If it is not plain text,
then the body is not directly displayed; instead, an external program called
metamail is invoked.  The metamail program is a simple switch that compares
the content-type of the current message to a configuration file (mailcap file)
that tells how various types of mail can be handled at the local site.  If a
handler is found for the current message type, the message is passed off to
that handler for presentation to the user.  Otherwise the user is informed
about the unrecognized data, rather than shown the (probably
incomprehensible) raw data stream.

Given this mechanism, it is easy to integrate computational email into a wide
variety of mail-reading agents.  Once those agents have been modified to use
the metamail software, as described above, it is simply a matter of installing
an interpreter for the computation mail language, and adding an appropriate
line to the local mailcap file.

ATOMICMAIL:  A Practical System for Computational Email

In accordance with the ideas described above, the author has designed a
language suitable for embedding computation in electronic mail, known as
ATOMICMAIL.2  The ATOMICMAIL software is designed to provide a secure
and portable language for distributed applications that use electronic mail as
a transport mechanism, or implement what might be called "User to User
Remote Procedure Call."

ATOMICMAIL Language Definition

ATOMICMAIL uses LISP [Steele, 1990] as its basic language model.  There is
nothing essential about LISP for this purpose, although it is a very clean
interpreted language, which eases the validation of the security mechanisms.
(It would be considerably harder to be sure about the security of a compiled
language, and particularly one like C [Kernighan and Ritchie, 1988] that
includes mechanisms (e.g. pointers) for accessing arbitrary memory locations.)
Of course, LISP is just a starting point.  As mentioned before, all input and
output facilities were removed from the basic language and replaced with
input and output mechanisms that did not compromise security and that were
portable to virtually any user interaction environment.

Thus, for example, LISP's READ primitive is gone, but new primitives such as
GETSTRING and GETBOOLEAN are defined.  Similarly, new file system
primitives permit a strictly limited access to a circumscribed local file system.

A complete specification of the ATOMICMAIL language is too lengthy and
detailed to be included here.  The language is, however, rigorously specified
in [Borenstein, 1990].  Figure 1 shows a small ATOMICMAIL program.

The Bellcore Prototype ATOMICMAIL Interpreter

Although a computational email language should be designed for portability
and abstraction of user interface, an implementation (interpreter) must
inevitably be grounded in some particular user interaction environment.
Based on the realities of the heterogeneous environment at Bellcore, the
initial ATOMICMAIL interpreter was written to use the curses library
[Arnold, 1984] for its user interface.  The prototype interpreter will,
therefore, run on any machine that is (or can emulate) a UNIX terminal.
Under window systems such as X11, a terminal emulator window is used.
This architecture clearly sacrifices a good deal of potential usability, but it
ensures that the facilities of computational email will be available to the
widest possible number of users.  A graphical (X11) interpreter for the same
ATOMICMAIL language is also planned.  The prototype ATOMICMAIL
interpreter uses, as its basic LISP engine, the Embedded LISP Interpreter
(ELI) from the Andrew Message System [Borenstein, 1991a].

Like any network service, the implementation of a computational email
system may be less secure than its specification.  A great deal of attention has
been paid, in the design of ATOMICMAIL, to ensure that there would be no
serious security problems in a hypothetical perfect implementation.  No
claims are made, however, that the prototype is such a perfect
implementation.  It seems likely that an ATOMICMAIL implementation is
neither more nor less likely to contain unexpected and accidental security
risks than any other network service software.

Figures 2 through 4 show the prototype ATOMICMAIL interpreter at work.

As of September, 1991, the ATOMICMAIL software has been deployed in at
least four different laboratories at Bellcore.  It is available to universities with
a royalty-free license for non-commercial use.

Initial Uses of ATOMICMAIL

The initial deployment of ATOMICMAIL has demonstrated that computational
email can be made to work portably and securely.   It has not, however,
proven that such a mechanism is worthwhile.  Before such a claim can be
made, it is necessary to have one or more substantial applications that are
highly valued by the user community.  While it is too early to evaluate their
overall utility, six applications have been prototyped at Bellcore:  a survey
generator, a meeting scheduler, a document distributor, an information finder,
an activist alert mechanism, and a distributed mail-based game.

The survey generator is a tool for generating simple surveys with
ATOMICMAIL.  With this tool, the user simply enters a set of questions (fill in
the blank, multiple choice, etc.) and the mail addresses to which he wants the
questions sent.  The recipients are surveyed interactively by an
ATOMICMAIL message, which then sends the response back as normal
electronic mail, or (optionally) sends it to a process which collates the results
and sends back only a high-level summary.

The meeting scheduler allows the person calling a meeting to specify the
purpose of the meeting, a list of participants, and a set of possible dates and
times for the meeting.  Each participant is surveyed via ATOMICMAIL, and
the results are collected and returned to the originator as a summary that
quickly shows which times, if any, everyone can make it.

The document distributor is a tool that makes it easy for someone who is
distributing documents to generate an ATOMICMAIL message that offers
recipients a scrollable list of document titles.  When a recipient selects a title,
he is shown an abstract of the document and asked whether he wants to
order it.  Orders are sent to a designated "fulfillment" address via normal
electronic mail.

The information finder is an application that maintains a database of
expertise within an organization.  Users are encouraged to send questions on
any topic to the information finder, which will use ATOMICMAIL to ask the
question of one or more relevant experts.  If the experts don't know the
answers, they are asked to suggest other experts, who are then surveyed in
turn.  This process continues, spreading out to more specialized and possibly
more distant experts, until an answer is obtained that satisfies the user.

The activist alert mechanism is a program that shows its recipient a brief text
explaining a "hot" political issue.  It then asks if the user wants to lobby his or
her elected officials on this topic.  If the user assents, the program verifies the
names of the user's elected representatives, and either generates a paper
copy of a letter to those representatives or sends a fax to them directly.
Finally, it asks the user if there are any other people to whom the alert
should be redistributed.

The "Name That Tune" game is an ATOMICMAIL version of the familiar game
show.  All of the "bidding" steps in the game are conducted via ATOMICMAIL.
In the final step of the game, a multipart message, including both audio and
ATOMICMAIL, is used to play the tune and ask the user to name it.

Earlier, ATOMICMAIL was also used to prototype another mail-related
service, dynamic mailing lists.  In this service, a message to a mailing list
contained, in addition to its normal text, an ATOMICMAIL component that
asked people whether or not they wanted to take part in further discussions
on the same topic.  In this case, although ATOMICMAIL facilitated a quick
prototype, it soon became obvious that the functionality was better
accomplished by modifying the message reading software so that even plain
text messages could be the start of new dynamic mailing lists.

Future Work

There are many directions for the future of ATOMICMAIL.  Beyond additional
and enhanced ATOMICMAIL application services, there are several other
promising directions for future work.  A graphical interpreter for the current
ATOMICMAIL language would both further demonstrate the interface-
independence of the language and make the execution of ATOMICMAIL
programs much more pleasant for those who could use it.  By incorporating
cryptographic techniques and digital signatures, it should be possible to
extend ATOMICMAIL's capabilities to allow users to permit more dangerous
actions to be executed when the mail is authenticated as coming from a
trusted source.  Another direction for extension would be to relax somewhat
the assumptions about user interface environments.  For example, an
ATOMICMAIL-like language that presumed the presence of a bitmap display
might permit substantially more interesting applications to be developed.
Overall, there is no shortage of promising new directions for research on
computational electronic mail.

Acknowledgements

The ATOMICMAIL project has been made possible by the enlightened
management with which Bellcore is generally blessed.  The development of
the language and the prototype software has benefited greatly from the many
clever people who have helped me with useful suggestions and
encouragement, including Bob Kraut, Al Buzzard, Jonathan Rosenberg, Louis
Gomez, John Patterson, Steve Rohall, Ralph Hill, Will Leland, Peter Clitherow,
Shoshana Hardt-Kornacki, Steve Uhler, Mike Bianchi, Scott Stornetta, Michael
Littman, Ron Underwood, Mike O'Dell, Nat Howard, Dana Chee, Mark Segal,
Steve Butera, Dave Sincoskie, Mark Donadio, Laurence Brothers, and, no doubt,
others whom I have inadvertently omitted.

References

[Ackerman and Malone, 1990]  Ackerman, M. and Malone, T., "Answer Garden:
A Tool for Growing Organizational Memory", Proceedings of the Conference on
Office Information Systems, Cambridge, Massachusetts, 1990]

[Anderson and Gillogly, 1976]  Anderson, R. H., and J. J. Gillogly, "Rand
Intelligent Terminal Agent (RITA): Design Philosophy", Rand Corporation
Technical Memorandum R-1809-ARPA, February, 1976.

[Arnold, 1984]  Arnold, Kenneth C. R. C., "Screen Updating and Cursor
Movement Optimization:  A Library Package", UNIX Programmer's Manual
Supplementary Documents, USENIX Association, 1984.

[Borenstein, 1990] Borenstein, Nathaniel S., "MAGICMAIL Language Reference
Manual", Bellcore Technical Memorandum.

[Borenstein, 1991a]  Borenstein, Nathaniel S., and Chris A. Thyberg, "Power,
Ease of Use, and Cooperative Work in a Practical Multimedia Message System",
International Journal of Man-Machine Studies, April, 1991.

[Borenstein, 1991b] Borenstein, Nathaniel S., "Multimedia Electronic Mail:  Will
the Dream Become Reality?", Communications of the ACM, April, 1991.

[Forsdick, 1984]  Forsdick, H.C., Thomas, R.H., Robertson, G. G., and Travers, V.
M., "Initial Experience with Multimedia Documents in Diamond", Computer
Message Service, Proceedings IFIP 6.5 Working Conference, IFIP, 1984.

[Grudin, 1990]   Grudin, J., "Seven plus one challenges for Groupware
Developers", Rev. of DAIMI PB 323 Aarhus University Computer Science
Department.

[Hansen, 1990]  Hansen, W. Fred, "Enhancing Documents with Embedded
Programs:  How Ness Extends Insets in the Andrew Toolkit", Proceedings of
IEEE Computer Society 1990 International Conference on Computer
Languages, New Orleans, 1990.

[Hogg, 1985]  Hogg, John, "Intelligent Message Systems", in Office Automation,
D. Tsichritzis, editor, Springer-Verlag, 1985.

[Kernighan and Ritchie, 1978]  Kernighan, Brian W., and Dennis M. Ritchie, The
C Programming Language, Prentice-Hall, 1978.

[Shepherd, 1990]  Shepherd, Allan, Niels Mayer, and Allan Kuchinsky, "Strudel
-- An Extensible Electronic Conversation Toolkit", Proceedings of CSCW '90,
October, 1990.

[Spafford, 1989]  Spafford, Eugene H., "The Internet Worm: Crisis and
Aftermath," Communications of the ACM, June, 1989.

[Steele, 1990]  Steele, Guy L., Common Lisp:  The Language, Second Edition,
Digital Press, 1990.

[Vittal, 1981]  Vittal, John, "Active Message Processing:  Messages as
Messengers", in Computer Message Systems, R. P. Uhlig, editor, North-Holland
Publishing Company, 1981.



Figures

Figure 1 -- program code for a simple survey

Figure 2 -- The ATOMICMAIL help screen

Figure 3 -- An ATOMICMAIL survey

1It should be noted that no ethically-trained software engineer would ever consent to
write a "DestroyBaghdad" procedure.  Basic professional ethics would instead require
him to write a "DestroyCity" procedure, to which "Baghdad" could be given as a
parameter.
2The original name for this language was MAGICMAIL, which stands for "Messages that
are Active Generate Innovation and Cooperation, but Mustn't Allow Internet Larceny."
Unfortunately, a trademark was unavailable, so the language has been renamed
ATOMICMAIL, which stands for "A Trademark On MAGICMAIL is Impossible; Clearly
Monikers Are Inhibited by Legalisms."